Proposed text that removes "WiFi is out of scope" and proposed operator token #153
Conversation
…or token to be used on e.g. WiFi
AxelNennker
requested review from
bigludo7 and
fernandopradocabrillo
as code owners
🦙 MegaLinter status: ✅ SUCCESS
See detailed report in MegaLinter reports MegaLinter is graciously provided by |
|
Hi @AxelNennker, thanks for the proposal. I'd propose to wait until camaraproject/IdentityAndConsentManagement#145 is closed to make this modification, otheruntil that moment the API is not ready to fulfill the Wi-Fi cases requirements. Additionally, I'd not separate the scenarios in two separated, instead we may need to think in a main (operator token) and fallback scenario (current network-based authcode) that can fulfill both options. Let's discuss it in a audio call, so we can also align other parts of the APi documentation that may require modifications. |
Co-authored-by: Rafal Artych <[email protected]>
Co-authored-by: Rafal Artych <[email protected]>
Co-authored-by: Rafal Artych <[email protected]>
Co-authored-by: Rafal Artych <[email protected]>
Co-authored-by: Rafal Artych <[email protected]>
Co-authored-by: Rafal Artych <[email protected]>
Co-authored-by: Rafal Artych <[email protected]>
Co-authored-by: Rafal Artych <[email protected]>
@jgarciahospital yes, the merging should be coordinated with camaraproject/IdentityAndConsentManagement#145. I wanted work on operator token here because NumberVerification is the "natural" use case for operator token.
It would be nice if you wrote "suggestions" for this PR with the text you prefer. If the discussion here gets lengthy and pros and cons of different ways to do it get hard to resolve, then the meeting is the best place to resolve differences. Regarding declaring operator token the main scenario, I think we are not there yet because the MNO has to have an endpoint that creates the operator token. Usually that endpoint is an Entitlement Server implementing GSMA's TS.43 Service Entitlement Configuration. This is a MNO business decision and a CAMARA business decisison. Here in this group we can enable technology and thereby enable business. @mengan discusses some variants how the API consumer can get an operator token in #86 (comment) Not all of them are "silent" at least not the first time. It is then for the API consumer to decide whether they want to send the user through that user interaction. The OS vendor might feel the need to ask the user for permission whether the user allows getting an operator token from the carrier for the API consumer at least once. All, please suggest text or propose topics to consider. Maybe we need a separate CAMARA document (in ICM) discussing e.g. operator token use cases. Or such a use case could be added to https://github.com/camaraproject/NumberVerification/blob/main/documentation/API_documentation/NumberVerification_verify_User_Story.md or both... |
Sorry, the github editor introduces blanks which the user cannot see.
Proposed text that removes "WiFi is out of scope" and proposes operator token to be used on e.g. WiFi
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
Currently NumberVerification only works if the access token is requested over a mobile connection because only a mobile network connection enables the Communications Provider/MNO to determine the subscriber be means of network-based authentication.
The PR removes text that restricts the use of the NumberVerification API to over a mobile connection.
The PR introduces text that states that an operator token, which is obtained after EAP-AKA, is an alternative to a mobile network connection.
If the API consumer has obtained an operator token, then operator token should be used by the API Consumer because the operator token is associated with information which operator has issued it, which enables e.g. an aggregator to route OIDC authorization code flow request to the communications provider/MNO.
Which issue(s) this PR fixes:
Fixes #86
Additional documentation
ICM Allow to use operator_token (from TS43) to identify device on authentication request
Operator Token TS.43 Service Entitlement Configuration
Operator Token Authorisation Sever – Authenticator Capabilities Group